System Software Task and Subsystem Descriptions

System Software Task and Subsystem Descriptions
 
This appendix describes the system and subsystem tasks running under StarOS on an ASR 5000 platform.
It includes the following sections:
Overview
For redundancy, scalability and robust call processing, StarOS is divided into a series of tasks that perform specific functions. These tasks communicate with each other as needed to share control and data signals. As a result, system processes can be distributed across multiple tasks thus reducing the overall work-load on any given task and improving system performance. This distributed design provides fault containment that greatly minimizes the impact to processes or sessions due to a failure.
All tasks run in a Common Firmware Environment (CFE) that resides on specialized Central Processing Units (CPUs) on each of the application cards. The System Management Cards (SMCs) each have a single CPU that is responsible for running tasks related to system management and control. The packet processing cards (PSCn, PPC) contain two CPUs (CPU 0 and CPU 1). These CPUs are responsible for session processing and running the various tasks and processes required to handle mobile data calls. In addition to the CPUs, the packet processing cards each have a Network Processor Unit (NPU) for IP forwarding.
The following sections describe the primary tasks that are implemented by the system:
Primary Task Subsystems
The individual tasks that run on the CPUs are divided into subsystems. Following is a list of the primary subsystems responsible for call session processing:
System Initiation Task (SIT): This subsystem starts tasks and initializes the system. This includes starting a set of initial tasks at system startup time (static tasks), and starting individual tasks on demand at arbitrary times (dynamic tasks).
High Availability Task (HAT): With the Recovery Control Task (RCT) subsystem, the HAT subsystem maintains the operational state of the system. HAT monitors the various software and hardware components of the system. If there are unusual activities, such as the unexpected termination of another task, the HAT subsystem takes a suitable course of action, such as triggering an event to the RCT subsystem to take corrective action or to report the status. The end result is that there is minimal or no impact to the service.
Recovery Control Task (RCT): This subsystem executes a recovery action for any failure that occurs in the system. The RCT subsystem receives signals from the HAT subsystem (and in some cases from the NPU subsystem) and determines what recovery actions are needed.
The RCT subsystem runs on the active SMC and synchronizes the information it contains with the RCT subsystem on the standby SMC.
Shared Configuration Task (SCT): This subsystem provides a facility to set, retrieve, and receive notification of system configuration parameters. The SCT is mainly responsible for storing configuration data for the applications that run on the system.
The SCT subsystem runs only on the active SMC and synchronizes the information it contains with the SCT subsystem on the standby SMC.
Resource Management (RM): This subsystem assigns resources, such as CPU loading and memory, for every system task upon start-up. The RM subsystem monitors resource use to verify that allocations are as specified. RM also monitors all sessions and communicates with the Session Controller to enforce capacity licensing limits.
Virtual Private Network (VPN): This subsystem manages the administrative and operational aspects of all VPN-related entities in the system. The functions performed by the VPN subsystem include:
All IP operations within the system are done within specific VPN contexts. In general, packets are not forwarded across different VPN contexts. The only exception currently is the Session subsystem.
Network Processing Unit (NPU): This subsystem is responsible for the following:
Card/Slot/Port (CSP): Coordinates the events that occur when any card is inserted, locked, unlocked, removed, shutdown, or migrated. SCP also performs auto-discovery and configures ports on a newly-inserted line card. It determines how line cards map to packet processing cards (through a Redundancy Crossbar Card [RCC], if necessary).
The CSP subsystem runs only on the active SMC and synchronizes the information it contains with the SCT subsystem on the standby SPC/SMC. It is started by the SIT subsystem and monitored by the HAT subsystem.
Session: Performs high-touch processing of mobile subscribers’ packet-oriented data session flows. High-touch user data processing consists of the following:
Primary Subsystem Controllers and Managers
Many of the primary subsystems are composed of critical tasks—controller tasks called Controllers, and subordinated tasks called Managers. Critical tasks are essential to the system’s ability to process calls, such as those in the SIT subsystem.
Controllers serve several purposes:
Managers manage resources and mappings between resources. In addition, some managers are directly responsible for call processing.
The following section provides information about the composition of the primary subsystems that are composed of critical, controller, and / or manager tasks.
ASR 5x00 Subsystems
The following tables describe managers and tasks performing within the specified subsystems on an ASR 5x00 platform.
Important: Variations regarding how the managers and tasks are distributed based on session recovery (SR) are included in the Card and CPU columns in some tables. Tables without these indicators are applicable to ASR 5x00s with and without session recovery. The ASR 5x00 dynamically distributes processes, tasks, and managers on startup. The following tables list the typical locations but variations can occur depending on available resources.
ASR 5x00 System Initiation Subsystem
ASR 5x00 High Availability Subsystem
ASR 5x00 Resource Manager (RM) Subsystem
ASR 5x00 Virtual Private Networking (VPN) Subsystem
ASR 5x00 Network Processing Unit (NPU) Subsystem
ASR 5x00 Session Subsystem
NOTE: With session recovery (SR) enabled, this demux manager is usually established on one of the CPUs on the first active packet processing card.
NOTE: With session recovery (SR) enabled, this demux manager is usually established on one of the CPUs on the first active packet processing card. The HNBMGRs should not be started on a packet processing card which has the HNB DEMUX MGR started.
NOTE: With session recovery (SR) enabled, this demux manager is usually established on one of the CPUs on the first active packet processing card.
NOTE: With session recovery (SR) enabled, this demux manager is usually established on one of the CPUs on the first active packet processing card.
NOTE: With session recovery (SR) enabled, this demux manager is usually established on one of the CPUs on the first active packer processing card.
NOTE: With session recovery (SR) enabled, this demux manager is usually established on one of the CPUs on the first active packet processing card.
NOTE: With session recovery (SR) enabled, this demux manager is usually established on one of the CPUs on the first active packet processing card, but should not be created on the same packet processing card that has HNB Manager.
NOTE: With session recovery (SR) enabled, this manager is usually established on one of the CPUs on the first active packet processing card. The HNBMGRs should not be started on a packet processing card which has the HNB DEMUX MGR started.
NOTE: With session recovery (SR) enabled, this demux manager is usually established on one of the CPUs on the first active packet processing card.
NOTE: With session recovery (SR) enabled, this demux manager is usually established on one of the CPUs on the first active packet processing card. The IMSIMgr will not start on a packet processing card in which SessMgrs are started.
NOTE: With session recovery (SR) enabled, this demux manager is usually established on one of the CPUs on the first active deumux packet processing card. The IMSIMgr will not start on a packet processing card in which SessMgrs are already started.
NOTE: With session recovery (SR) enabled, this demux manager is usually established on one of the CPUs on the first active packet processing card.
NOTE: With session recovery (SR) enabled, this demux manager is usually established on one of the CPUs on the first active packet processing card.
NOTE: With session recovery (SR) enabled, this demux manager is usually established on one of the CPUs on the First active packet processing card but should not be created on the same packet processing card that has MME Manager.
NOTE: With session recovery (SR) enabled, this demux manager is usually established on one of the CPUs on the first active packet processing card. The MMEMGRs should not be started on a packet processing card which has the MME DEMUX MGR started.
NOTE: With session recovery (SR) enabled, this demux manager is usually established on one of the CPUs on the first active packet processing card but should not be created on the same packet processing card that has PCC Manager.
NOTE: With session recovery (SR) enabled, this manager is usually established on one of the CPUs on the first active packet processing card. The PCCMGRs should not be started on a packet processing card which has the PCC BINDMUX MGR started.
The Sp interface is based on Sh protocol interface. The SPRMgr abstracts the Sp interactions required for the PCC functions.
NOTE: With session recovery (SR) enabled, this demux manager is usually established on one of the CPUs on the first active demux packet processing card. The IMSIMgr will not start on a packet processing card in which SessMgrs are already started.
NOTE: With session recovery (SR) enabled, this demux manager is usually established on one of the CPUs on the first active demux packet processing card. The IMSIMgr will not start on a packet processing card in which SessMgrs are already started.
ASR 5x00 Platform Processes
ASR 5x00 Management Processes
 
 

Cisco Systems Inc.
Tel: 408-526-4000
Fax: 408-527-0883